LOCATION-BASED TESTING FOR WIRELESS 
DATA COMMUNICATION NETWORKS 

Related Applications 

[0001] The present application claims the benefit of United States Provisional 

Patent Application Serial Number 60/460,640 filed on April 4, 2003. 
Field of the Invention 

[0002] The present invention relates to wireless data communication networks 
and, more specifically, to location-based testing for wireless data communication 
networks. 

Background to the Invention 

[0003] Wireless Local Area Networks (WLANs) have recently gained in 

popularity and importance. These networks are a special case of standard computer 
Local Area Networks (LANs), where the wires or optical fibers interconnecting computers 
have been partially or completely replaced by radio frequency (RF) data links. WLANs 
may also be viewed as a special case of commonly encountered cellular telephone 
networks, where the relatively large distances in the order of tens of miles covered by 
cellular telephones have been significantly reduced to hundreds of feet, (within buildings) 
in exchange for much higher data transmission rates. WLANs offer the possibility of 
interconnecting information technology devices at relatively high speeds without wires, 
and hence yield significant reductions in installation cost together with significant 
improvements in user convenience. 

[0004] The increased usage and reliance upon WLANs has in turn dictated an 

increase in the level of performance and functionality testing that must be carried out in 
order to ensure that the WLAN protocol has been properly implemented and that WLAN 
equipment will function predictably, reliably and robustly under all circumstances. 
Without a significant level of testing, it is not possible to guarantee this reliability and 
performance. 

[0005] In general, WLAN testing and characterization seeks to achieve the same 

goals as traditional wired LAN testing. The following categories of tests must be earned 
out: 

(a) Performance measurements. These tests seek to determine some 
metrics of network performance, such as data rate (typically measured in bits per 
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second), bit or frame error ratios, system utilization, latency, burst tolerance, etc. 
Performance measurements are normally carried out by transmitting test stimulus data 
at various speeds to the device under test and making quantitative measurements on 
the response from the device. 

(b) Conformance tests. These tests attempt to quantify the level of 
adherence of the device to a set of specifications or requirements. These specifications 
may include published standards (e.g., the IEEE 802.1 1 standard for WLANs). They are 
usually carried out by presenting a set of well-defined patterns or stimuli to the device 
under test and verifying that the device responds as per the specification to each set of 
stimuli. 

(c) Interoperability tests. These tests are used to ensure that two or more 
devices from different sources can intercommunicate without problems. Interoperability 
tests can be done by utilizing test equipment to simulate or emulate devices with which 
interoperability is desired, and measuring the responses of the device under test to 
ensure that the expected values are matched. 

(d) Diagnostic tests. Diagnostic tests are performed during design and 
development to expose any faults or design errors in the device that may be causing 
performance, conformance or interoperability tests to fail. These are typically performed 
with the same test equipment, but set up instead to generate arbitrary stimuli to the 
device under test and record its responses. 

[0006] Unlike wired LANs, however, WLANs have created a number of 

significant problems related to performance and functionality testing and 
characterization. The complexity of the protocol required to implement the high-speed 
data transfers is quite high, requiring correspondingly more complex and detailed testing 
capability. A single piece of WLAN equipment may need to communicate with multiple 
computers or end-stations, all sharing the same spectrum and in close proximity to each 
other. This renders the interactions observed between the equipment and the end- 
stations more complex and less predictable. The attenuation and multipath 
characteristics of the RF channel used to communicate between the WLAN equipment 
and the end-stations can cause significant variations in behavior and performance. 
Interference can also occur between WLAN equipment located in the same or adjacent 
buildings, even though they are physically isolated. All of these render the WLANs 
testing many times more complex than the testing for traditional wired or fiber-optic 
LANs. 



[0007] Implementation and testing of WLAN networks, equipment and 

components is hence very different from that of standard wired LANs such as Ethernet. 
An important difference is that location is a significant parameter within the test 
environment; changing the location of equipment has virtually no impact on a wired LAN, 
but creates a huge impact on a WLAN system. Therefore, wired LAN testing methods 
and test equipment are quite unsuitable for WLAN testing, and a substantially new 
approach is required. This new approach, and the apparatus required to realize it, are 
the subjects of the present invention. 

[0008] The key factor that distinguishes protocol testing of wireless data 

communication networks such as WLANs from that of wired LANs is the concept of 
location aware protocol testing. Location awareness here refers to the fact that the exact 
three-dimensional spatial location of a WLAN device, relative to the other WLAN devices 
and to the environment in which it is placed, is of great significance in the performance 
and functioning of the WLAN and must be accounted for. For example, shifting the 
position of a WLAN device by a few feet (e.g., placing it in a different room) can 
materially affect the throughput or interference seen by the device. This is clearly not the 
case for wired LAN technologies, which operate using copper or fiber optic links that are 
substantially insensitive to changes in physical location. This means that WLAN test 
systems must support the ability to account for the three-dimensional spatial location of 
the device or system being tested. In addition, the tests performed upon a device or 
system at a particular location cannot be reproduced at a different location without also 
duplicating some or all of the characteristics of the original location. Such duplication 
may be performed either directly (i.e., re-creating the physical environment of the device 
or system) or indirectly (i.e., by simulating the characteristics of the physical 
environment, without duplicating it in its entirety). The latter is clearly much simpler. 



Summary of the Invention 

[0009] It is an object of the invention to provide an improved wireless data 

communication protocol tester. It is a further object of the invention to provide a wireless 
data communication protocol tester that enables the location-dependent characteristics 
of wireless data communication networks to be accounted for during protocol testing. 
[0010] It is yet a further object of the invention to provide a wireless data 

communication protocol tester that enables the location-dependent characteristics of a 
wireless data communication network environment to be simulated at a different location 
without reproducing the entire physical environment. 

[001 1 ] In a first aspect, the present invention provides a test unit for testing 

operation and measuring performance of wireless data communication systems and 
equipment, comprising: a protocol test unit for generating test stimulus data, executing a 
sequence of test steps selected for testing operation and measuring performance of said 
wireless data communication systems, and processing test result data; a location 
processor, operatively coupled to said protocol test unit, for generating spatial location 
data providing the location of said protocol test unit relative to a preset point; and a first 
interface unit, operatively coupled to said protocol test unit, for converting said test 
stimulus data to a first format specific to said object under test and for converting said 
test result data to a second format specific to said protocol test unit. 
[0012] In a second aspect, the present invention provides a test system for 

testing operation and measuring performance of wireless data communication systems 
and equipment, comprising: n test units, each test unit for selectively testing a specific 
parameter and data protocol pertinent to an object under test, where n is an integer 
ne[1, N]; a location processor on each said test units for determining the location of 
each said test unit relative to a pre-set point; a central controller for monitoring, 
controlling and coordinating operation of said test units and collecting test results data 
associated with said respective spatial location data; and a user interface for enabling 
selection of test sequences, configuration of traffic generation and of test parameters. 
[0013] In a third aspect, the present invention provides a method of testing 

operation and measuring performance of wireless data communication systems and 
equipment, comprising: a) providing n test units in the proximity of an object under test 
and connecting said test units to a central controller, where n in an integer ne[1, NJ; b) 
initializing a connection between said test units and said central controller; c) configuring 
at each said test unit traffic generation, a test sequence, and a set of reporting 
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parameters according to said test sequence; d) operatively controlling said test units for 
executing said test sequence; e) collecting test result data at said test units and 
associating said test result data with a respective test unit; and f) organizing, reviewing 
and analyzing said test result data. 

[0014] In a fourth aspect, the present invention provides a test system for testing 

operation and measuring performance of wireless data communication systems having 
both a wireless network portion and a wired network portion, comprising: n test units, 
each test unit for selectively testing a specific parameter and data protocol pertinent to 
an object under test in said wireless data communication systems, where n is an integer 
ne[1, NJ; a location processor on each said test units for determining the location of 
each said test unit relative to a pre-set point; a central controller for monitoring, 
controlling and coordinating operation of said test units and collecting test results data 
associated with said respective spatial location data; and a user interface for enabling 
selection of test sequences, configuration of traffic generation and of test parameters; 
wherein at least one of said n test units includes a wireless network interface unit for 
testing a wireless object in said wireless network portion, and wherein at least one of 
said n test units includes a wired network interface unit for testing a wired object in said 
wireless network portion. 

[0015] Advantageously, the test units may be responsive to high-level 

instructions for performing protocol tests or sequences of protocol tests from the central 
controller, and process these high-level instructions in order to generate data bit 
patterns, analysis functions and control functions that are required by the protocol 
generation and processing means. 
Brief Description of the Drawinas 

[0016] The description of the preferred embodiments is taken in conjunction with 

the accompanying drawings, wherein: 

[0017] Figure 1 is a diagram illustrating a general arrangement of the test units 

and the central controller in relation to the device or system under test; 

[0018] Figure 2 is a schematic block diagram showing the details of a single test 

unit; 

[0019] Figure 3 is a schematic block diagram of the RF interface unit circuitry; 

[0020] Figure 4 is a schematic block diagram of the circuitry for the location 

determining means; 



[0021] Figure 5A is a schematic block diagram of the circuitry for the Ethernet 

LAN interface that may be used to implement the communication means with the central 
controller; 

[0022] Figure 5B is a schematic block diagram of the circuitry for the UHF radio 

data link that may be used to implement the communication means with the central 
controller; 

[0023] Figure 6 is a representation of the user interface implemented by the 

central controller; 

[0024] Figure 7 is a diagram illustrating an arrangement of test units and the 

central controller wherein the air interfaces between the test units and a device under 
test have been replaced by cables; 

[0025] Figure 8 depicts the process of setting up, initializing, configuring and 

operating the test units and analyzing the results; 

[0026] Figure 9 depicts an example of a sequence of instructions executed by a 

test unit when carrying out a specific protocol test; and 

[0027] Figure 1 0 is a schematic block diagram showing the details of a single 

test unit with a wired network interface. 
Description of the Preferred Embodiments 

[0028] With reference to Figure 1 , the wireless data communication protocol test 

system comprises a general-purpose computer 14 that is programmed to act as a 
central controller, and a plurality of identical test units 10, 11, 12, 13 that perform the 
actual traffic generation and reception functions during the process of protocol testing of 
device or system under test 1 5. Term "object under test" is also used for item 1 5, to 
collectively designate a device or a system under test. As all of the test units 1 0, 1 1 , 12, 
13 are preferably identical, it is understood that a reference to an aspect of any specific 
test unit, e.g. 1 0, shall be hereinafter taken to apply to all of the other test units in the 
system, e.g., 1 1 , 1 2, 1 3. It is further understood that the number of test units 10 in the 
system may range from 1 to any arbitrary number required to perform a specific test or 
to simulate a specific wireless data communications network. 
[0029] The central controller 14 communicates with each test unit as shown at 

17. Each test unit 10 is a compact device that can be placed at various locations around 
or within the device or system under test 15 and generates and receives wireless data 
streams 16 to and from the latter. Each test unit 10 may be programmed to simulate a 



WLAN access point (AP), a WLAN endstation (STA), or both, or may be set up to simply 
monitor traffic being generated or received by the device or system under test 15. 
[0030] The central controller 14 preferably utilizes a standard host computer or 
workstation, such as a personal computer, and executes user-interface and control 
software. A comprehensive control and analysis program is implemented on the central 
controller 14 in order to control and co-ordinate the test units. User control of the test 
units is accomplished through a Graphical User Interface (GUI). An example of a GUI 
window 100 is shown in Figure 6, and described in detail in the accompanying text. In 
general, GU1 100 provides the user with access to analysis tools (filters, statistics 
calculation, charting etc.) as well as provides the ability to format and output analysis 
reports, and communicate with the test units 10, 11, 12, 13 via UHF or Ethernet 
communication means 17. 

[0031] With reference to Figure 2, each test unit 10 preferably comprises a - 

protocol test generation and processing unit 20, an RF interface unit 21 coupled to 
antenna 22, either directly or indirectly, that generates and receives wireless data 
streams to and from the device or system being tested; a communications interface unit 
23 coupled to communications link 17 that serves to communicate with the central 
controller 14, and a location processor 27, coupled to location processor antenna 28. 
Test generation and processing unit 20 executes the test unit control software 26 and 
includes a storage 25 for tests and test results. Location processor 27 calculates the 
spatial location of the test unit 10 in three dimensions relative to the central controller 14 
in order to determine the position of the test unit 10 within the environment surrounding 
the device or system under test 15. 

[0032] The location processor 27, RF interface unit 21, and communications 

interface unit 23 are operatively coupled to protocol test generation and processing unit 
20, and are preferably implemented as plug-in cards to allow simple upgrading, either 
during manufacturing or in the field. For instance, future support for newer WLAN 
protocols may be accomplished by inserting a different RF interface unit 21. 
[0033] The protocol test generation and processing unit 20 is preferably 
constructed around a high-speed embedded CPU 30 and associated peripherals that 
are operatively coupled to CPU bus 31. The CPU 30 is interfaced to program storage 33 
and data storage 34. Program storage 33 may be implemented using Flash Electrically 
Erasable Programmable Read-only Memory (Flash EEPROM), while data storage 34 
may advantageously be implemented using Synchronous Dynamic RAM (SDRAM) for 
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maximum speed and data capacity. At least 32 megabytes of Flash EEPROM, plus at 
least 64 MB of SDRAM, may be implemented. 

[0034] The CPU 30 is also interfaced to bus control logic 32 that is operatively 

coupled to synchronization logic 35 as well as to interfaces 37, 38 and 39. Location 
interface 37 couples to location processor 27; RF interface 38 couples to RF interface 
unit 21 ; and communication interface 39 couples to communications interface unit 23. 
The CPU utilizes bus control logic 32 to implement the control and data transfer 
functions required to support location processor 27, RF interface unit 21 and 
communications interface unit 23. 

[0035] The CPU 30 exercises overall control and co-ordination of location 

processor 27 and RF interface unit 21, maintains the communication link 17 to central 
controller 14 via communications interface unit 23 (preferably supporting a TCP/IP 
protocol stack in order to simplify the communications functions), and communicates 
with the central controller 14 to perform test set-up and report test results. The CPU 30 
may also implement firmware programs required for performing the protocol testing and 
analysis functions. 

[0036] Synchronization logic 35 is operative to provide a clock reference 

frequency for use by RF interface unit 21 in generating wireless data bit streams of the 
proper data rate and phase alignment. It is coupled to synchronization inputs and 
outputs 36, which may be advantageously connected to the corresponding 
synchronization inputs and outputs 36 of other test points in order to align all the data bit 
streams produced by these test points. In addition, synchronization logic 35 provides the 
timing reference required to mark the times at which wireless data bit streams have been 
received by RF interface unit 21. Synchronization logic 35 is preferably implemented 
using a temperature-compensated high-stability Voltage Controlled Crystal Oscillator 
(VCXO), implemented as part of a Phase Locked Loop (PLL), that generates a stable 
and precise 10 MHz clock reference locked to a 100 pulse-per-second (PPS) signal that 
is either generated internally or received from another test unit via synchronization inputs 
and outputs 36. 

[0037] With reference to Figure 3, RF interface unit 21 comprises a WLAN RF 

front-end unit 42, a WLAN baseband processor unit 41 , and protocol pre-processing 
logic 40. 

[0038] WLAN RF front-end unit 42 is operative to implement the radio frequency 

amplification, frequency conversion, and analog signal processing functions such as 
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Automatic Gain Control (AGC), as required by the physical layer of the wireless data 
communication protocol. Further, WLAN RF front-end unit 42 implements attenuation 
functions such that the RF signal output by RF interface unit 21 to antenna 22 may be 
controlled to a high degree of precision, and the detection threshold for the RF signal 
input to RF interface unit 21 by antenna 22 may also be controlled to a high degree of 
precision. These attenuation functions permit the RF interface unit 21 to simulate the 
effect of increased attenuation of radio signals through the environment, as would be 
found, for example, if the test unit 10 and the device under test 15 were separated by a 
greater distance. Also, antenna 22 coupled to WLAN RF front-end circuitry 42 may 
advantageously be replaced with a connectorized coaxial cable in situations requiring 
direct connection from test unit 10 to device under test 15, as for example when device 
under test 15 is to be tested as a closed system and not as part of a larger environment, 
or for example when it is desired to exclude external signal interference from various 
sources. 

[0039] WLAN baseband processor 41 is operative to perform the signal 

modulation and demodulation functions required by the physical layer of the wireless 
data communication protocol. These functions may advantageously be implemented 
using digital signal processing circuitry. 

[0040] Protocol pre-processing logic 40 provides hardware acceleration 

functions to assist protocol test generation and processing unit 20, of Figure 2, in 
carrying out the required protocol tests. In addition, it may contain the timing logic 
necessary for the precise bit-level timing requirements of WLAN baseband processor 41, 
and may further implement a serial control interface to support the configuration and 
monitoring of WLAN baseband processor 41 and WLAN RF front-end 42. 
[0041] In one embodiment, protocol pre-processing logic 40 may include on the 

receive side a deserializer (serial to parallel converter) 53, a timing marker 52, a receive 
First In First Out (FIFO) buffer 51, and a protocol processor interface logic 50. On the 
transmit side, protocol pre-processing logic 40 may include a transmit FIFO buffer 54, an 
output timer logic 55, and a serializer (parallel to serial converter) 56. The clocking and 
synchronization of the protocol pre-processing logic 40 is controlled by a master clock 
logic and clock offset control logic 57. The logic interfaces with the WLAN baseband 
processor 41 via baseband receive input 58 and baseband transmit output 59, both of 
which convey serial data. 



[0042] Deserializer 53 converts the incoming serial data stream demodulated by 

the baseband processor 41 into a parallel data stream of preferably 8 bits in width. This 
data stream is passed to timing marker logic 52, which detects the start and end of the 
data stream constituting each received frame and time-stamps the start and end points 
with an accurate time indication derived from master clock logic 57. The time-stamped 
data stream is then placed in receive FIFO 51, and subsequently passed to the protocol 
test generation and processing logic 20 by protocol processor interface logic 50 through 
RF interface bus 38. 

[0043] Transmit data, preferably in 8-bit byte format, are obtained from the 

protocol test generation and processing logic 20, of Figure 2, by protocol processor 
interface logic 50 via RF interface bus 38 and placed into transmit FIFO 54. The data 
are then passed to output timer logic 55, which controls the precise time at which each 
word of transmit data will be passed to serializer 56. Timing references are provided by 
master clock logic 57 to output timer logic 55. The parallel data presented to serializer 56 
are then converted to serial form and placed on baseband transmit output 59 for later 
modulation and transmission by WLAN baseband processor 41. 
[0044] The master clock logic 57 is responsible for generating the clock signals 

required by the receive and transmit paths of protocol pre-processing logic 40. These 
clock references are phase-locked to the accurate clock reference generated by 
synchronization logic 35. In addition, master clock logic 57 is capable of adding or 
subtracting an adjustable offset delay to the clock reference obtained from 
synchronization logic 35 prior to creating the actual receive and transmit clock signals. 
This enables the protocol pre-processing logic 40 to simulate the effect of propagation 
delays through the environment. For instance, an increased offset delay is equivalent to 
the effect of increasing the distance between the test unit 1 0 and the device or system 
under test 15. 

[0045] It is understood that different air interface standards (IEEE 802. 1 1 

Wireless LAN, Bluetooth, HiperLAN, etc.) may be accommodated by substituting the 
appropriate baseband processing function 41 and RF front-end function 42 in RF 
interface 21 . It will be apparent to persons skilled in the art that the protocol test 
generation and processing unit 20 is realized in a general fashion using firmware running 
on CPU 30, and hence support of wireless data communications protocols is simply a 
matter of replacing RF interface 21 and reprogramming the firmware. 
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[0046] With reference to Figure 4, location processor 27 may be advantageously 

implemented using the Global Positioning System (GPS) to determine the absolute 
three-dimensional spatial co-ordinates of test unit 10, and subsequently computing the 
three-dimensional vector from the test unit 10 to the central controller 14 in order to 
ascertain the relative position of test unit 10. The location processor 27 consists of GPS 
RF front end unit 81 , operatively coupled to location processor antenna 28, and GPS 
baseband processor 80. Standard GPS processing is performed on the GPS satellite 
navigation signals received by location processor antenna 28 to compute the three- 
dimensional co-ordinates of test unit 10, and these co-ordinates are passed to protocol 
test generation and processing logic 20 by means of location interface 37. 
[0047] A communications link is required between the test unit 10 and the central 

controller 14 in order for the central controller 14, of Figure 1, to configure and control 
test unit 10 and also to receive test results. This communications link may preferably be 
implemented using either Ethernet or a dedicated UHF radio link. The communications 
link is supported by implementing one instance of communications interface unit 23 in 
each test unit 10, and one similar instance of communications interface unit 23 in the 
central controller 14. If Ethernet is being used, a standard Ethernet repeater or switch 
(not shown) may preferably be used to permit all of the test units 1 0, 1 1 , 1 2, 1 3 to 
communicate with the central controller 14. If a UHF radio link is being used, the central 
controller 14 may advantageously implement a polling or time-division-multiplexing 
protocol to allow communications with all of test units 10, 11, 12, 13 without requiring 
multiple instances of communications interface unit 23 to be present at the central 
controller 14. The realization of such polling or time-division-multiplexing protocols in 
radio links is well understood and will not be described further. 
[0048] With reference to Figure 5A, communications interface unit 23 may be 

implemented using the standard Ethernet communications protocol. In this case, 
Ethernet MAC logic 60 performs the required Ethernet packet processing and medium 
access control functions, and Ethernet Physical Layer Device (PHY) logic 61 implements 
the Ethernet physical layer functions required to interface to Ethernet link 62, which in 
turn is used to communicate with central controller 14. Ethernet MAC logic 60 is 
operatively coupled to protocol test generation and processing logic 20, of Figure 2, by 
means of communications interface 39. 

[0049] With reference to Figure 5B, communications interface unit 23a is an 

alternative implementation using a dedicated UHF radio data link operating in a suitable 
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frequency band, preferably 430 MHz. The dedicated UHF radio data link comprises UHF 
antenna 75 coupled to RF filters and transmit/receive switch 73, which is in turn coupled 
to UHF serial data transmitter 71 and UHF serial data receiver 72. Serializer/deserializer 
(SERDES) and data processor 70 converts between parallel data transferred to or from 
the protocol test generation and processing logic 20 via communications interface 39 
and serial data streams that are generated by UHF serial data receiver 72 and accepted 
by UHF serial data transmitter 71 . Clock generator 74 implements a clock synthesis 
function that generates the necessary bit-clock, carrier and frequency conversion signals 
required by the UHF serial data transmitter 71 and UHF serial data receiver 72. Multiple 
UHF channels may be supported by reconfiguring clock generator 74 to generate 
different carrier frequencies. 

[0050] With reference to Figure 6, the software program executed by central 

controller 14 displays and maintains a Graphical User Interface (GUI) 100 that interacts 
with the user of the protocol test system and controls the operation of test units 10 
through communication links 17, together with an underlying control program supporting 
GU1 100. The specific capabilities of GU1 100 and underlying control program preferably 
include: 

(a) Detection, checking, initialization and configuration of the test units in the 
system; 

(b) Display of test unit status; 

(c) Grouping of test units under user command to simulate Basic Service 
Sets in the WLAN protocol; 

(d) Configuration of traffic generation parameters; 

(e) Display and editing of test control sequences; 

(f) Configuration of traffic monitoring and capture filters; 

(g) Display of traffic counters, and support of a traffic counter spreadsheet; 

(h) Display of test unit location in a 3-D window; 

(i) Display of captured frame data; 

0) Saving, restoring and execution of test control sequences; 

(k) Display of measured traffic characteristics in charts and histograms; 

(I) Saving and restoring of frame, counter and chart/histogram log files; 

(m) Download and update of firmware on the test units; and 

(n) Inter-test unit synchronization during startup. 
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[0051] GU1 100 and associated control program may advantageously enable the 

user to download firmware images stored on the central controller to the test units 10, 
1 1 , 12, 13, thereby allowing the test units to be upgraded in capabilities and features in 
the field. 

[0052] GU1 100 display preferably includes a menu bar 101 that displays menus 

of commonly used commands, a test unit selection and grouping window 102, a test 
setup and results window 103, a test sequence control window 104, a statistics counter 
window 105, a3-D view window 106 and a test unit status window 107. 
[0053] Test unit selection and grouping window 1 02 shows the plurality of test 

units 10 available to the user for the test, and permits the user to select and group these 
test units in any arbitrary combination in order to perform test setup and execution. Test 
setup and results window 103 enables the user to set up test units and monitor their 
results, either singly or in groups. Test sequence control window 104 allows the user to 
define and execute sequences of protocol test actions on one or more test units, and to 
organize these sequences in a hierarchical manner so as to construct complex test 
sequences from blocks of simpler test sequences. Statistics counter window 1 05 
displays the statistics (packets or bytes transmitted and received, errors, histograms of 
packet lengths, etc.) accumulated by test units, either singly or in groups. The 3-D view 
window 106 displays a three-dimensional view (as a 2-D projection) of the set of test 
units and the device under test, using the spatial location information gathered from the 
test points. Finally, test unit status window 107 displays the status of individual test units 
that are selected via test unit selection and grouping window 102 or via 3-D view window 
106. 

[0054] User interactions with GU1 1 00 are translated by the underlying control 

program into sets of instructions that are transferred to test units 10 via communications 
links 17. Each set of instructions is executed by CPU 30 in the corresponding test unit 10 
in order to perform a specific protocol test or tests. The results are returned to GU1 100 
via communications links 17 and subsequently displayed in one or more of the windows 
of GU1 100. 

[0055] With reference to Figure 7, test units 1 0, 1 1 , 1 2, 1 3 may advantageously 
support an auxiliary arrangement whereby microwave-rated cables 81, 82, 83, 84 are 
used instead of an air interface (i.e., without utilizing antennas) to carry signals between 
the test units 1 0, 1 1 , 1 2, 1 3 and a device under test 1 5. This arrangement makes use of 
a standard passive microwave power splitter/combiner module 85 to combine the signals 
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from multiple test units 10, 1 1, 12, 13 and drive them to the device under test 15 via 
cable 86, as well as to split the signals from the device under test 15 equally among the 
test units 1 0, 1 1 , 12, 1 3. This type of cabled setup is only feasible if the device under test 
15 supports connectorized antenna inputs (e.g., an auxiliary RF input, or removable 
antennas with standard connectors) or if device under test 15 can be placed in an RF- 
shielded chamber to which cables 81 , 82, 83, 84 are coupled. When cabled in this 
manner, synchronization between test units 10, 11, 12, 13 is preferably accomplished by 
means of cables running directly between the synchronization inputs and outputs 36 
coupled to synchronization logic 35 implemented in each test unit. A mechanical 
mounting in the form of a chassis or rack may advantageously be provided to further 
facilitate convenient operation of test units 10, 1 1, 12, 13 using cabled setups. 
[0056] Operation of the wireless data communication protocol test system 

depicted in Figure 1 is completely initiated and controlled via GU1 100 running on the 
host computer serving as central controller 14. GU1 100 converts operator commands 
that are input via a keyboard and mouse into high-level command messages directed at 
one or more of the test units 10, 1 1, 12, 13; these command messages are then passed 
to the specified test units via the appropriate communications links 17 (i.e., Ethernet or 
UHF radio). System operation preferably begins with an initialization phase, followed by 
the actual test configuration and execution phase. Post-processing and report 
generation may then follow the test phase, after tests have been executed and results 
gathered by GU1 100 from the test units. 

[0057] With reference to Figure 8, a typical usage scenario may include the 
steps of: 

(a) At step 111, setting up the test units 1 0, 1 1 , 1 2, 1 3 at the desired 
locations around the device or system under test 15 and powering them on. 

(b) At step 112, starting up GU1 1 00 on the central controller 1 4 to 
display the top-level screen, verifying that the required test units 10, 11, 12, 13 have 
been detected and initialized, and then optionally grouping them into logical groups as 
desired using the test unit selection and grouping window 102 of GU1 100. 

(c) At step 1 1 3, configuring parameters, if necessary, for the traffic 
generation to be performed by the groups of test units, and then setting up sequences of 
traffic to be generated by each test unit, using test setup and results window 103. The 
user may also optionally set up capture and monitoring filters controlling the data capture 
by each test unit using the same window. 
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(d) At step 1 14, executing the sequence(s) on the test units that have 
been selected to participate in the test, using test sequence control window 104. 

(e) At step 1 1 5, reviewing the data captured by the test units and 
presented on statistics counter window 105, test unit status window 107, and test setup 
and results window 103, in order to ascertain whether the device or system under test 15 
is functioning properly, whether additional tests need to be run. and, further, optionally 
invoking post-processing analysis and report generation functions on the captured data. 

(f) At step 1 1 6, checking to see if more tests need to be run; if not, at 
step 117 terminating the test procedure by exiting GU1 1 00 and powering down the test 
units. 

[0058] Initialization of the wireless data communication protocol test system at 

step 112 takes place immediately after GU1 100 is started, may include three stages: test 
unit polling and discovery, timing synchronization, and test unit location. The system 
initialization process preferably happens automatically (when the GU1 100 is started); 
however, it may also be initiated and controlled by the user via the GU1 100. Also, the 
initialization phase may advantageously include firmware upgrades to the test units 10, 
11, 12, 13 under user control. 

[0059] The first stage in the initialization process preferably includes polling for 

and discovering all of the test units that are available. The set of test units thus found is 
reported to the user, who may then be allowed to modify the set by removing or 
reassigning test units that are not intended to participate in the subsequent tests. The 
process of polling for test units may advantageously occur at regular intervals while GUI 
100 is running, in order to detect when new test units have been added to the system, or 
if an existing test unit has been removed or has failed during a test. 
[0060] The initialization process preferably then ensures that the internal real- 

time clock within each of the test units 10, 11, 12, 13 are synchronized. This is done with 
the aid of synchronization logic 35 that is implemented as a part of protocol test 
generation and processing unit 20, of Figure 2. Synchronization inputs and outputs 36 
coupled to synchronization logic 35 in each test unit are used to exchange timing signals 
between the test units in order to bring the clock references generated by master clock 
57, of Figure 3, of all of the test units into synchronism. After synchronization has been 
performed, the final stage of initialization preferably includes obtaining the precise three- 
dimensional location of each of the test units by means of location processor 27. Central 
controller 14 may poll for the three-dimensional coordinates of each test unit 10, and 
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report the results to the user via test unit status window 107. The central controller 14 
may advantageously improve location accuracy by transmitting differential GPS (DGPS) 
corrections to the test units 10, 1 1, 12, 13, at this time, if DGPS information is available. 
[0061] Subsequent to initialization 112, each test unit 10 is preferably configured 

from central controller 14 prior to running tests, as shown in step 113. Configuration may 
include the steps of setting up RF interface unit 21 to match the test requirements, 
configuring traffic patterns and monitoring parameters to be used during the tests by 
protocol test generation and processing unit 20, and defining reporting options for test 
results to be sent back to central controller 14. 

[0062] Configuration of RF interface unit 21, of Figure 3, is relatively 

straightforward and may include writing parameters to its internal registers. The 
parameters to be written preferably cover such aspects as data rate, preamble length, 
scrambler seeds, antenna selection controls, tone generation, receiver AGC control, and 
transmitter power level. All of these parameters may be advantageously adjustable by 
the user via GU1 100. 

[0063] Traffic patterns and monitoring configuration at step 113 comprises at 

least two aspects: traffic monitoring configuration and traffic generation configuration. 
Traffic monitoring configuration parameters set up each test unit 10 to gather traffic 
streams and characteristics, and may include error filters, frame capture filters, event 
filters (e.g., inter-frame spacing thresholds) and counter update controls. Traffic 
generation configuration parameters may be used to determine the nature of traffic 
(frames or interference) that will be transmitted by the test units, and preferably include 
frame data values, data payload patterns, error injection parameters, traffic stream 
parameters (e.g., inter-frame spacing, burst lengths, etc.) and test sequence scripts. 
[0064] Reporting configuration parameters may be advantageously specified 

during step 1 13 in order to reduce the amount of data that has to be returned to the 
central controller 14 when test results are downloaded from the test units 10, 1 1 , 12, 13. 
These configuration parameters may control the counters that maintain traffic statistics, 
as well as the types of frames that may be captured and reported during the test, plus 
the fields within captured frames that are actually stored. Reporting configuration 
parameters preferably takes the general form of pattern-matching filters, which specify 
frame data patterns and event conditions on which to update specific counters and also 
to capture data. Additional pattern-matching filters may be used to define the portions of 
captured frames that have to be retained in internal buffers. The use of such pattern- 
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matching filters for frame analysis is well-known in the prior art and will not be described 
further herein. 

[0065] Execution of the test procedure configured at step 1 13 is accomplished at 

step 1 14 by protocol test generation and processing unit 20, and may consist of 
generating traffic for stimulating the device or system under test 15 as well as recording 
its responses. 

[0066] During the execution of the test procedure, each test unit 10 may perform 

continuous, real-time traffic monitoring, and record a comprehensive set of events, 
statistics and traffic data within its on-board memory. The types of records maintained in 
the memory of each test unit 10 preferably include: 

(a) event records, such as clear-channel assessment, acquisition, 
coding violations, etc.; 

(b) captured wireless data frames (in whole or in part), selected 
according to filters defined during configuration step 113; 

(c) interface-dependent parameters associated with captured wireless 
data frames, such as total length, data rate, received signal strength, signal quality, etc.; 

(d) error parameters associated with captured wireless data frames, 
such as CRC errors, illegal frame lengths, illegal frame types, and illegal frame field 
values; 

(e) predefined statistics counters that accumulate counts of different 
events, including received and transmitted data and control frames of various types, 
received and transmitted octets, frame size histograms, frames received from specific 
addresses, etc.; and 

(f) user-defined auxiliary statistics counters that accumulate counts of 
the number of frames that match set of user-configured filter parameters, as well as the 
number of frame octets corresponding to those frames. 

[0067] The following additional types of records may advantageously be 

maintained in the memory: 

(a) predefined min/max variables that record various extrema 
pertaining to the transmitted and received traffic streams, including the maximum 
medium busy time, the minimum IFS, the maximum and minimum packet lengths, etc.; 

(b) user-defined auxiliary min/max variables that record the minimum 
and maximum time interval between any two types of user-selectable packet filters; and 
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(c) tables that record wireless data frame fields, including addresses, 
that are associated with the received traffic, with each table being preferably of a 
predefined maximum size, and new entries added to a table preferably overwriting the 
oldest entries when the table becomes full. 

[0068] Each record may be associated with a timestamp that indicates when it 

was created or updated. The timestamp preferably has a precision of 1 nanosecond and 
an accuracy no worse than that of the master clock 57 within each test unit 10. 
[0069] The information gathered during the execution of the test procedure at 
step 1 14 may advantageously be placed into a database maintained by CPU 30 in 
protocol test generation and processing unit 20 for retrieval by the user via GU1 100 on 
the central controller 14. The user is preferably provided with a single view of the 
databases in all of the active test units, to simplify the process of retrieving and 
analyzing data. The test units 10, 11, 12, 13 therefore comprise a single distributed 
database of monitored information that can be queried at will. 
[0070] During execution of the test procedure at step 1 14, the protocol 

generation and test processing unit 20 in each test unit 10 may further generate wireless 
data traffic for device and system testing as well as network performance analysis. Such 
traffic may include three categories: specific frame sequences used to test device 
functions and protocol compliance, continuous traffic generated to measure system 
throughput, and illegal data generated to test the robustness of the device or system 
under test 15. 

[0071] Compliance testing of device or system under test 1 5 to a particular 

wireless data communication standard is preferably performed by creating specific 
command sequences on GU1 100 and executing them on test units 10, 1 1, 12, 13 in 
order to generate traffic to exercise various aspects of the protocol. Examples of such 
protocol compliance test sequences for the Wireless LAN protocol include association 
and authentication handshakes, RTS/CTS handshakes, inter-frame spacing tolerance 
sequences. 

[0072] Figure 9 depicts an example of a test sequence as displayed on test 

sequence control window 104 of GU1 100. This sequence illustrates the process of 
generating a WLAN frame transfer protocol compliance check, including the steps of 
waiting for a Request To Send (RTS) frame, sending a Clear To Send (CTS) frame, 
waiting for a Data frame to arrive within the specified interval of 10 microseconds, 
sending an Acknowledge (ACK) frame in response, and then repeating the process 100 
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times to ensure that the device under test 15 is compliant to this portion of the WLAN 
protocol. It is clear from Figure 9 that each test unit 10 is capable of conditioning the 
execution of test sequences based on responses from the device under test; for 
instance, the sequence illustrated causes the test unit 10 to wait for a specific frame to 
be transmitted by the device under test 1 5 before proceeding with the rest of the 
sequence, which allows complex protocol handshakes to be properly supported. 
[0073] Throughput measurements on device or system under test 1 5 may further 

be supported by test units 10, 1 1 , 12, 13. Throughput measurements require the test 
units to continuously generate back-to-back frames with the minimum interframe spacing 
specified by the wireless data communications protocol, while supporting all of the 
handshaking requirements of the protocol. In the case of WLANs, such handshaking 
requirements may include association, authentication, RTS/CTS exchanges, Data/ACK 
exchanges, and so on. The throughput measurements supported by the wireless data 
communication protocol test system include: sustained traffic throughput, burst traffic 
throughput, traffic focusing (multiple endstations to one access point or endstation) 
throughput, database capacity tests (addresses, association IDs, etc.), frame size 
handling and interframe gap tolerance. 

[0074] Interference tests on device or system under test 1 5 may further be 

supported by test unit 10, 1 1, 12, 13. Such interference tests include: 

(a) Collision interference. Test units 1 0, 1 1 , 1 2, 1 3 may monitor 
transmissions from device or system under test 15 and deliberately collide at specified 
locations within specified frames transmitted by the device, in order to permit the 
measurement of the device's ability to perform retransmissions. In addition, the test units 
10, 1 1, 12, 13 may advantageously be set up to collide with each other, to allow the 
collision detection capabilities of the device under test 15 to be verified. Collisions are 
preferably performed by simply transmitting a random bit pattern via RF interface unit 21 
while the device under test 15 is still transmitting a data packet. 

(b) Continuous wave interference. Test units 10,11,12,13 may be 
configured to generate a continuous unmodulated carrier at the center frequency of any 
given wireless data communications channel, in order to simulate the effect of a tone 
jammer on the operation of device under test 15. 

(c) Spread-spectrum interference. Test units 1 0, 1 1 , 1 2, 1 3 may be 
configured to output a continuous pseudorandom bitstream, not organized as valid 
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wireless data frames, and confined to a specific channel. This measures the ability of the 
device under test 15 to cope with signal-to-noise ratio impairments. 

(d) Adjacent-BSS interference. A subset of test units may be 
configured to simulate a distant BSS operating within the same channel as a local BSS 
of which the device under test 15 is a part. Simulation of a distant BSS is performed by 
configuring the subset of test units to operate at reduced power and larger delay relative 
to the remainder of the test units, thereby emulating the attenuation and path delay 
experienced in the actual environment. 

[0075] The synchronization logic 35, together with master clock and clock offset 
control 57 in each test unit 10 may be advantageously used to permit the rigid alignment 
of sequences among test units 10, 11, 12, 13, so that any test unit, e.g. 10, generates 
traffic at precisely determined times with respect to all other test units, e.g. 1 1, 12, 13. 
This permits the user to simulate specific traffic patterns, perform throughput and latency 
tests, and simulate interference in a highly deterministic and repeatable manner. As an 
example, two or more such synchronized test units 10, 1 1 may be configured to perform 
closely aligned back-to-back transactions with one device under test 1 5 in order to 
measure performance in a traffic focusing scenario. 

[0076] Reporting of test results to the user via GU1 1 00 for review and analysis 

may take place continuously during the test execution, or may take place after the test 
execution has completed. Reported results include statistics counters, transmitted and 
received frames, and the real-time status of each test unit 10. 
[0077] Each test unit 1 0 should preferably report a user-selectable set of 

statistics counters to the controller for display in the statistics counter window 1 05 of GUI 
100. These statistics counters include counts of received and transmitted frames, counts 
of transmitted multicast frames, counts of failed transmits, counts of retried transmits, 
counts of duplicate frames received, counts of control frames received and transmitted, 
counts of errored frames received, counts of bytes received and transmitted, and counts 
of fragmented frames received and transmitted. The protocol test generation and 
processing unit 20 preferably ensures that the counters are coherent, i.e., the values 
being displayed are all measured at the same instant in time. GU1 100 may 
advantageously support a display mode wherein counters from multiple test units 10, 1 1, 
12, 13 are displayed simultaneously, in a side-by-side organization to permit the user to 
make quick comparisons of counter values from the different test units. In place of a 
side-by-side display, GU1 100 may further support a spreadsheet form of counter display 
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that permits the user to perform arithmetic operations using one or more counter values 
from one or more test units, the results of which are displayed and updated concurrently 
with the counters themselves. This form of display is very useful for making throughput, 
packet loss and error rate measurements. 

[0078] Each test unit 10 should preferably transfer the frames received by RF 

interface unit 21 and filtered by protocol test generation and processing unit 20 to the 
GUI 100 on the central controller 14 under user command during or after the test 
execution, for display on test setup and results window 103. GU1 100 may 
advantageously support a further display mode wherein frames from multiple test units 
10, 1 1, 12, 13 are displayed simultaneously, in a side-by-side organization to permit 
quick comparisons. 

[0079] Each test unit 1 0 should preferably present its operational status 

continuously to the central controller 14 for display in the test unit status window 107 of 
GU1 100. The status information displayed includes: the health of the test unit (whether 
running, idle or faulty); the current location of the test unit in three dimensions; the 
current transmit power setting; key fields of the last frame received by the test unit 
(addresses, received power, etc.); and the group to which the test unit belongs. 
[0080] The wireless data communication protocol test system may further 
support the following special functions to aid the user in setting up and monitoring tests, 
and handling the location-sensitive nature of wireless data communication networks: 

(a) 3-D display window 106 in GU1 1 00. This window is used to 
display ail of the test units in their 3-dimensional spatial locations relative to the central 
controller 14, and may also be used to display the computed location of the device under 
test 15. The spatial locations are obtained from location processor 27. The 3-D window 
106 may be coupled into the remainder of the underlying control program running on 
central controller 14 and GU1 100, such that test units can be selected by clicking on 
them in the window. In addition, the system may support the automatic specification of 
artificial delays and attenuation factors introduced into sequences run by different test 
units 10, 1 1, 12, 13 (thereby simulating the effect of locating test units at different 
positions within the environment) by permitting the user to drag the icons associated with 
the test units to different locations within the 3-D window. This in turn causes the 
configuration of RF interface unit 21 in each of the test units 10, 1 1, 12, 13 to be updated 
automatically such that the transmitted power and receiver thresholds are modified to 
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reflect the effect of the different channel attenuation, and the master clock and clock 
offset control 57 is adjusted to reflect the effect of the different path delay. 

(b) Test unit selection and grouping window 102 in GU1 100. This 
window allows the user to group test units 10, 1 1, 12, 13 into one or more subsets, 
assign names to each group, and then manipulate all of the test units in each group as a 
unit. For instance, it is advantageous to start and stop all of the test units in a group 
simultaneously, thereby repeatably emulating the effect of stations at multiple points in a 
wireless network beginning their transmissions simultaneously. The grouping of test 
units may also be used to apply traffic generation and monitoring parameters to all of the 
test units in a group, if the group is first selected prior to modifying the parameters, 
thereby simplifying the task of setting up the parameters for a group. 
[0081] It is apparent that the teachings of the present invention enable the 

protocol testing of wireless data communication devices or networks having location 
sensitive characteristics to be performed in a simpler and more deterministic manner, 
with a higher degree of reliability and a reduced burden upon the user. It is further 
apparent that the location-sensitive characteristics of the wireless data communication 
device or network may be accounted for and tested during the protocol testing process. 
It is further apparent that the present invention provides for the simulation of the location- 
dependent characteristics of a wireless data communications network during protocol 
testing of wireless data communication devices or systems. 
[0082] The present invention may also be modified to provide the following 

embodiments: 

(a) Inclusion of record/replay functions. With reference to FIG 2, RF interface 
unit 21 is capable of continuously receiving wireless data communication signals from 
antenna 22, and passing these signals to protocol test generation and processing unit 20 
for storage in test and result storage memory 25. Further, RF interface unit 21 is capable 
of continuously accepting bit data from protocol test generation and processing unit 20 
for transmission as wireless data communication signals from antenna 22. These 
functions can be advantageously coupled to permit recording and future replay of 
wireless data communication signals, such that a sequence of signals may be initially 
recorded in permanent or semi-permanent form in test and result storage 25 and later 
replayed via RF interface unit 21 to regenerate the same sequence of signals exactly. 

Such record/replay functions are very useful for diagnostic purposes, wherein a 
signal or packet sequence evoking a defect in a device or system under test may be 
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captured and recorded, and later replayed as many times as necessary to re-create the 
defect and permit it to be fixed. In addition, such record/replay functions are useful for 
capturing a sequence of signals at one location (for example, a user environment) and 
later reproducing the same sequence of signals at another environment (for example, a 
laboratory). The ability of the present invention to emulate the location-sensitive 
characteristics of an environment is of significant benefit in this case. 

(b) Provision of a multi-protocol RF interface unit 21 in test unit 1 0. The 
present invention may be extended to support the testing of multiple wireless data 
communication protocols without requiring multiple types of test units by modifying RF 
interface unit 21 to support these different protocols. For example, it is possible to 
support the IEEE 802.1 1b and IEEE 802.11a, both WLAN data communication protocols, 
by adapting RF interface unit 21 to support the physical layers specific to both IEEE 
802.1 1b and IEEE 802.1 1a; as the underlying MAC protocol is identical for both, it is 
possible to simultaneously test devices conforming to either or both protocols by using 
only one set of test units 1 0, 1 1 , 1 2, 1 3. 

(c) Provision of a channel simulator 1 30 in front of RF interface unit 21 in test 
unit 10. A channel simulator is a device, well known in the prior art, that emulates the 
physical characteristics of a wireless transmission channel, including the various types of 
impairments that may be present in the channel, such as attenuation, phase shifts, 
fading, multipath effects, noise and interference. With reference to Figure 2, the 
placement of a channel simulator 140, as alternatively shown with dashed lines, 
between RF interface 21 and antenna 22 would permit the physical aspects of the 
wireless channel to be exactly emulated, rather than the approximate emulation possible 
by adjusting the delay, output power and receiver threshold of RF interface 21 . This, in 
turn, would allow more accurate emulation of the location-sensitive properties of a 
wireless data communication environment to be performed. 

(d) Provision of a wired network interface unit. Most wireless data 
communication networks incorporate a wired portion as well; for instance, the access 
points of a WLAN are linked together using a wired network (typically Ethernet), and the 
basestations of a cellular network are connected to the cellular switching system via 
wired transmission trunks. With reference to Figure 10, the present invention may be 
extended to include the testing of the wired portion of the wireless data communication 
networks by providing a wired network interface unit 140 in test unit 11, in place of RF 
interface unit 21 in test unit 10 of Figure 2. This would enable simultaneous testing of 
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the wired and wireless portions of a wireless data communications network; the test 
units with standard RF interface units 21 would be positioned and configured to generate 
wireless test data signals, and the test units, such as test unit 1 1 with wired network 
interfaces shown in Figure 10, would be attached to the wired network portions of the 
data communications network. Communications unit 23 depicted in Figure 5A may be 
utilized with the wired network interface unit 140 in a test unit to support an Ethernet test 
interface, for example. 

[0083] Accordingly, while this invention has been described with reference to 

illustrative embodiments, this description is not intended to be construed in a limiting 
sense. Various modifications of the illustrative embodiments, as well as other 
embodiments of this invention, will be apparent to persons skilled in the art upon 
reference to this description. 
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